Aspects of the present invention relate to data transmission. Other aspects of the present invention relate to authenticated data transmission.
In the age of computers, software systems are developed to facilitate various types of services. For example, a bank may develop a series of programs running on a computer and interacting with either a bank personnel or a user to perform different banking tasks. A corporation may develop its web site, offering not only information about the company but also sales of its products.
An application program, simple or complex, is often organized as a hierarchy of functions or subroutines, each of which performs a pre-determined and well-defined functionality. Invoking combinations of different functions allows a system to perform diversified tasks. For example, an application system may invoke first a function to perform calculation of cost of a sale, which subsequently invokes another function, responsible for printing, to print out the calculated cost sheet. In a different task, it may first invoke a function that performs a web-based transaction, which then invokes the same printing function to print out, over the web, a transaction agreement. The printing function here is invoked by different functions and, in both instances, the printing function is running at a lower level in a call stack. In the first task, the underlying call stack consists of at least two levels, including the function to calculate a sale cost and the printing function. In the second task, the underlying call stack consists of also at least two levels, one is the function performing a web-based transaction and the other is the printing function.
At run time, a function in a call stack may error. Such an error may lead to a chain effect. That is, if a called function errors and fails to produce the result its calling function desires, the calling function may subsequently generate errors as well due to a subsequent effect of failing to perform pre-determined functionality using the desired result from its called function. In many software systems, each function that errors may independently output error codes. Such produced error codes are often limited to only programmatic errors. In addition, when a called function errors and outputs its error codes, its calling function may error as well and produce different error codes. In reality, when a running system fails to perform, operators depend on such error codes to determine the cause of the failure and correct the system based on the identified cause. Since most error codes are far from human readable or reasonably understandable, diagnosing the root cause of a run time error often requires extensive expertise and familiarity with the internal design of the software system. This requirement is not only demanding but also often unrealistic.
In a complicated computer application system, a call stack may become very deep. In this case, identifying the root cause based on a long list of error codes without the information associating the error codes from different levels of functions can be a daunting task. Even when human readable error information is provided, since it is often made available immediately after a function call returns, it requires an operator to handle associated error message immediately after the error is reported. In a real scenario, especially with a complex system having a deep call stack, it is usually not feasible.